Initial Registration Request Processing

A summary of the device's handling of registration requests (REGISTER messages) is as follows:

■

The URL in the SIP To header of the REGISTER message constitutes the primary Address of Record (AOR) for registration (according to SIP standards). If the To header's URL includes the "user=phone" parameter, then only the user part of the URL constitutes the AOR. If the To header's URL doesn't include the "user=phone" parameter, then both the user part and host part of the URL constitutes the AOR.

■

The device can save other AORs in its registration database as well. When the device searches for a user in its' registration database, any of the user’s AORs can result in a match.

■

The device's Classification process for initial REGISTER messages is slightly different than for other SIP messages. Unlike other requests, initial REGISTER requests can’t be classified according to the registration database.

■

If registration succeeds (replied with 200 OK by the destination server), the device adds a record to its' registration database, which identifies the specific contact of the specific user (AOR). The device uses this record to route subsequent SIP requests to the specific user (in normal or survivability modes).

■

The records in the device's registration database include the Contact header. The device adds every REGISTER request to the registration database before manipulation, allowing correct user identification in the Classification process for the next received request.

■

You can configure Call Admission Control (CAC) rules for incoming and outgoing REGISTER messages. For example, you can limit REGISTER requests from a specific IP Group or SRD. Note that this applies only to concurrent REGISTER dialogs and not concurrent registrations in the device's registration database.

The device provides a dynamic registration database that it updates according to registration requests traversing it. Each database entry for a user represents a binding between an AOR (obtained from the SIP To header), optional additional AORs, and one or more contacts (obtained from the SIP Contact headers). Database bindings are added upon successful registration responses from the proxy server (SIP 200 OK). The device removes database bindings in the following cases:

■

Successful de-registration responses (REGISTER with Expires header that equals zero).

■

Registration failure responses.

■

Timeout of the Expires header value (in scenarios where the UA did not send a refresh registration request).